Cache Sharing in Virtual Clusters

ABSTRACT

Shared memory caching resolves latency issues in computing nodes associated with a cluster in a virtual computing environment. A portion of random access memory in one or more of the computing nodes is allocated for shared use by the cluster. Whenever local cache memory is unable in one of the computing nodes, a cluster neighbor cache allocated in a different computing node may be utilized as remote cache memory. Neighboring computing nodes may thus share their resources for the benefit of the cluster.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to information handlingsystems, and more particularly relates to memory sharing betweenphysical nodes in a compute cluster.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option is an information handling system. An information handlingsystem generally processes, compiles, stores, or communicatesinformation or data for business, personal, or other purposes.Technology and information handling needs and requirements can varybetween different applications. Thus information handling systems canalso vary regarding what information is handled, how the information ishandled, how much information is processed, stored, or communicated, andhow quickly and efficiently the information can be processed, stored, orcommunicated. The variations in information handling systems allowinformation handling systems to be general or configured for a specificuser or specific use such as financial transaction processing, airlinereservations, enterprise data storage, or global communications. Inaddition, information handling systems can include a variety of hardwareand software resources that can be configured to process, store, andcommunicate information and can include one or more computer systems,graphics interface systems, data storage systems, networking systems,and mobile communication systems. Information handling systems can alsoimplement various virtualized architectures. Data and voicecommunications among information handling systems may be via networksthat are wired, wireless, or some combination.

SUMMARY

Shared memory caching mitigates latency issues in computing nodesassociated with a cluster in a virtual computing environment. A portionof random access memory in one or more of the computing nodes isallocated for shared use by the cluster. Whenever local cache memory isunavailable in one of the computing nodes, a cluster neighbor cacheallocated in a different computing node may be utilized as remote cachememory. Neighboring computing nodes may thus share their resources forthe benefit of the cluster.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures are not necessarily drawn to scale.For example, the dimensions of some elements may be exaggerated relativeto other elements. Embodiments incorporating teachings of the presentdisclosure are shown and described with respect to the drawings herein,in which:

FIG. 1 is a block diagram illustrating an information handling systemaccording to an embodiment of the present disclosure;

FIGS. 2-3 illustrate a virtual computing environment, according toexemplary embodiments;

FIGS. 4-5 illustrate cache sharing, according to exemplary embodiments;

FIGS. 6-8 illustrate more details of cache sharing, according toexemplary embodiments;

FIG. 9 illustrates memory sizing, according to exemplary embodiments;and

FIG. 10 is a flowchart illustrating a method or algorithm for cachesharing, according to exemplary embodiments.

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION OF THE DRAWINGS

The following description in combination with the Figures is provided toassist in understanding the teachings disclosed herein. The descriptionis focused on specific implementations and embodiments of the teachings,and is provided to assist in describing the teachings. This focus shouldnot be interpreted as a limitation on the scope or applicability of theteachings.

FIG. 1 illustrates a generalized embodiment of information handlingsystem 100, according to exemplary embodiments. For purpose of thisdisclosure information handling system 100 can include anyinstrumentality or aggregate of instrumentalities operable to compute,classify, process, transmit, receive, retrieve, originate, switch,store, display, manifest, detect, record, reproduce, handle, or utilizeany form of information, intelligence, or data for business, scientific,control, entertainment, or other purposes. For example, informationhandling system 100 can be a personal computer, a laptop computer, asmart phone, a tablet device or other consumer electronic device, anetwork server, a network storage device, a switch router or othernetwork communication device, or any other suitable device and may varyin size, shape, performance, functionality, and price. Further,information handling system 100 can include processing resources forexecuting machine-executable code, such as a central processing unit(CPU), a programmable logic array (PLA), an embedded device such as aSystem-on-a-Chip (SoC), or other control logic hardware. Informationhandling system 100 can also include one or more computer-readablemedium for storing machine-executable code, such as software or data.Additional components of information handling system 100 can include oneor more storage devices that can store machine-executable code, one ormore communications ports for communicating with external devices, andvarious input and output (I/O) devices, such as a keyboard, a mouse, anda video display. Information handling system 100 can also include one ormore buses operable to transmit information between the various hardwarecomponents.

Information handling system 100 can include devices or modules thatembody one or more of the devices or modules described above, andoperates to perform one or more of the methods described above.Information handling system 100 includes a processors 102 and 104, achipset 110, a memory 120, a graphics interface 130, include a basicinput and output system/extensible firmware interface (BIOS/EFI) module140, a disk controller 150, a disk emulator 160, an input/output (I/O)interface 170, and a network interface 180. Processor 102 is connectedto chipset 110 via processor interface 106, and processor 104 isconnected to chipset 110 via processor interface 108. Memory 120 isconnected to chipset 110 via a memory bus 122. Graphics interface 130 isconnected to chipset 110 via a graphics interface 132, and provides avideo display output 136 to a video display 134. In a particularembodiment, information handling system 100 includes separate memoriesthat are dedicated to each of processors 102 and 104 via separate memoryinterfaces. An example of memory 120 includes random access memory (RAM)such as static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM(NV-RAM), or the like, read only memory (ROM), another type of memory,or a combination thereof.

BIOS/EFI module 140, disk controller 150, and I/O interface 170 areconnected to chipset 110 via an I/O channel 112. An example of I/Ochannel 112 includes a Peripheral Component Interconnect (PCI)interface, a PCI-Extended (PCI-X) interface, a high-speed PCI-Express(PCIe) interface, another industry standard or proprietary communicationinterface, or a combination thereof. Chipset 110 can also include one ormore other I/O interfaces, including an Industry Standard Architecture(ISA) interface, a Small Computer Serial Interface (SCSI) interface, anInter-Integrated Circuit (I²C) interface, a System Packet Interface(SPI), a Universal Serial Bus (USB), another interface, or a combinationthereof. BIOS/EFI module 140 includes BIOS/EFI code operable to detectresources within information handling system 100, to provide drivers forthe resources, initialize the resources, and access the resources.BIOS/EFI module 140 includes code that operates to detect resourceswithin information handling system 100, to provide drivers for theresources, to initialize the resources, and to access the resources.

Disk controller 150 includes a disk interface 152 that connects the disccontroller 150 to a hard disk drive (HDD) 154, to an optical disk drive(ODD) 156, and to disk emulator 160. An example of disk interface 152includes an Integrated Drive Electronics (IDE) interface, an AdvancedTechnology Attachment (ATA) such as a parallel ATA (PATA) interface or aserial ATA (SATA) interface, a SCSI interface, a USB interface, aproprietary interface, or a combination thereof. Disk emulator 160permits a solid-state drive 164 to be connected to information handlingsystem 100 via an external interface 162. An example of externalinterface 162 includes a USB interface, an IEEE 1194 (Firewire)interface, a proprietary interface, or a combination thereof.Alternatively, solid-state drive 164 can be disposed within informationhandling system 100.

I/O interface 170 includes a peripheral interface 172 that connects theI/O interface to an add-on resource 174 and to network interface 180.Peripheral interface 172 can be the same type of interface as I/Ochannel 112, or can be a different type of interface. As such, I/Ointerface 170 extends the capacity of I/O channel 112 when peripheralinterface 172 and the I/O channel are of the same type, and the I/Ointerface translates information from a format suitable to the I/Ochannel to a format suitable to the peripheral channel 172 when they areof a different type. Add-on resource 174 can include a data storagesystem, an additional graphics interface, a network interface card(NIC), a sound/video processing card, another add-on resource, or acombination thereof. Add-on resource 174 can be on a main circuit board,on separate circuit board or add-in card disposed within informationhandling system 100, a device that is external to the informationhandling system, or a combination thereof.

Network interface 180 represents a NIC disposed within informationhandling system 100, on a main circuit board of the information handlingsystem, integrated onto another component such as chipset 110, inanother suitable location, or a combination thereof. Network interfacedevice 180 includes network channels 182 and 184 that provide interfacesto devices that are external to information handling system 100. In aparticular embodiment, network channels 182 and 184 are of a differenttype than peripheral channel 172 and network interface 180 translatesinformation from a format suitable to the peripheral channel to a formatsuitable to external devices. An example of network channels 182 and 184includes InfiniBand channels, Fibre Channel channels, Gigabit Ethernetchannels, proprietary channel architectures, or a combination thereof.Network channels 182 and 184 can be connected to external networkresources (not illustrated). The network resource can include anotherinformation handling system, a data storage system, another network, agrid management system, another suitable resource, or a combinationthereof.

FIGS. 2-3 illustrate a virtual computing environment 200, according toexemplary embodiments. Here the information handling system 100 mayprovide virtual computing and/or virtual hardware resources to one ormore client devices 202. While FIG. 2 only illustrates a few clientdevices 202, in practice there may be many client devices, perhaps evenhundreds or thousands of client machines. Regardless, the informationhandling system 100 may lend or share its hardware, computing, andprogramming resources with one of the client devices 202. The clientdevices 202 communicate with the information handling system 100 using acommunications network 204 to send and receive electronic data. Theelectronic data is packetized into packets of data according to a packetprotocol (such as any of the Internet Protocols). The packets of datacontain bits or bytes of data describing the contents, or payload, of amessage. A header of each packet of data may contain routing informationidentifying an origination address and/or a destination address. Theinformation handling system 100 and the client devices 202 may thusinspect the packets of data for routing information.

The virtual computing environment 200 shares resources. Thecommunications network 204 thus allows the information handling system100 to operate as a virtual, remote resource. Virtual computing is wellknown, so this disclosure need not delve into the known details. Sufficeit to say that the information handling system 100 may present oroperate as one or more virtual desktops (VD) or machines 210. Each oneof the virtual desktops 210 may provide some processing or applicationresource to any of the client devices 202. While FIG. 2 only illustratestwo virtual desktops 210 a and 210 b, the number or instantiations maybe several or even many, depending on complexity and resources.

FIG. 3 illustrates a cluster 220 in the virtual computing environment200. There may be any number of information handling systems 100operating as nodes in the cluster 220. Clustering is usually carried outto provide high availability (i.e., redundancy in the case of nodefailure). For simplicity, though, FIG. 3 only illustrates two (2) of theinformation handling systems (illustrated, respectively, as referencenumerals 100 a and 100 b). Each one of the information handling systems100 a and 100 b may thus host multiple virtual desktops (such as 210 athrough 210 d). The virtual computing environment 200 may thus presentshared resources for hundreds or thousands of the client devices 202.The information handling systems 100 a and 100 b may communicate usingthe packetized communications network 204, as is known.

Memory sharing may be desired. As the virtual computing environment 200may provide resources to hundreds or thousands of the client devices202, optimal management techniques may be desired. As the client devices202 make requests for data or processing, some of the shared resourcesmay be over utilized. The virtual computing environment 200 may thusshare cache memory among the information handling systems 100 in thecluster 220.

FIGS. 4-5 illustrate cache sharing, according to exemplary embodiments.Here exemplary embodiments may share cache memory within the cluster220. When the information handling system 100 provides virtual resourcesto any client device 202, input/output (I/O) data 230 may be generated.As the reader may understand, the I/O data 230 is received, sent, and/orgenerated when communicating with input/output devices. This disclosurewill mainly describe the I/O data 230 when reading data from, or writingdata to, the hard disk drive (HDD) 154. The I/O data 230, though, may beobtained when reading and writing to any hardware peripheral (such as anoptical drive, keyboard, monitor/display, printer, or USB memorydevice). FIG. 4 illustrates the I/O data 230 being stored in the memory120 (such as RAM) of the information handling system 100. The I/O data230, however, may be locally stored in other memory devices or remotelystored at any accessible/addressable location using the communicationsnetwork 204. The I/O data 230 may be one or more disk blocks, with eachdisk block being a sequence of bits or bytes of data having a characterlength. Exemplary embodiments may optimize caching of frequently useddisk blocks to the memory 120. Some popular disk blocks may be cached tothe RAM 120, so the capacity of the information handling system 100 toaccept disk I/O requests without latency may be increased, as a higherpercentage of these requests will be redirected to RAM. A greaterpercentage of the I/O operations per second (IOPS) will thus be cachedto RAM, thus increasing the capacity of the host machines in the virtualcomputing environment 200.

FIG. 5 further illustrates the virtual computing environment 200. InFIG. 5, the virtual computing environment 200 has the multiple nodes orhosts (such as the information handling systems 100 a and 100 b)arranged or clustered as the cluster 220. The nodes 100 a and 100 b inthe cluster 220 may thus generate many disk blocks of the I/O data 230.Indeed, in actual implementation, as each one of the informationhandling systems 100 a and 100 b provides virtual resources, the cluster220 may store and retrieve millions or even trillions of the disk blocksof the I/O data 230.

Exemplary embodiments may thus share cache memory for the I/O data 230.Each computing node in the cluster 220 may create a configurable portionof its respective cache memory 120 for shared use. For example,information handling system 100 a allocates a cluster neighbor cache 240a in its RAM 120 a. The cluster neighbor cache 240 a is available foruse by the other information handling system 100 b within the cluster220. The information handling system 100 b, similarly, allocates itscorresponding cluster neighbor cache 240 b in its RAM 120 b. The clusterneighbor cache 240 b is available for use by the other informationhandling system 100 a. Again, FIG. 5 is a simple illustration of thetwo-nodal cluster 220. In actual practice, though, the cluster 220 mayhave several or even many computer nodes, with each node designating itscorresponding cluster neighbor cache 240 for shared use. Each clusterneighbor cache 240 a and 240 b may be reserved to the cluster membernodes for caching of the I/O data 230. Each node, in other words, setsaside or allocates a predetermined amount of the RAM memory 120 as aread cache for disk read instructions from the local node, plus anadditional portion of the RAM memory 120 is set aside as the clusterneighbor cache 240 for usage by other nodes in the cluster 220.Computing nodes may thus share their individual cache memory for thebenefit of the cluster 220.

Exemplary embodiments may thus dynamically manage the RAM memory 120.Exemplary embodiments may use the remote direct memory access (RDMA)protocol to minimize access latency in the cluster neighbor cache 240.When the I/O data 230 is read from the hard disk drive 154, exemplaryembodiments may first attempt to store or cache the I/O data 230 to itslocal RAM 120 a. However, if for any reason, the local RAM 120 a is fullor otherwise unavailable, the information handling system 100 a may sendthe I/O data 230 (via the communications network 204 illustrated in FIG.4) to the cluster neighbor cache 240 b established in the informationhandling system 100 b. When the information handling system 100 a laterneeds the I/O data 230, the information handling system 100 a may thencall, query, and/or retrieve the I/O data 230 from the cluster neighborcache 240 b established in the information handling system 100 b.

Polling schemes may be used. While any prioritization or schedulingscheme may be used, exemplary embodiments may sequentially poll theneighboring cluster member nodes for availability. When cache memorysharing is implemented, exemplary embodiments may poll cluster nodes forstatus and availability. The information handling system 100 a, forexample, may poll the information handling system 100 b for an availablecapacity of its cluster neighbor cache 240 b. A larger cluster 220, ofcourse, would have more nodes, so exemplary embodiments may store ormaintain a dynamic member list of cluster nodes that participate incache memory sharing. Once any or all of the cluster neighbor caches 240in the cluster 220 have been fully populated, cluster nodes may then usetheir normal cache replacement policies (such as First-In, First-Out,Least-Frequently Used, and other known overwrite schemes) to replace anyold I/O data 230.

FIGS. 6-8 illustrate more details of cache sharing , according toexemplary embodiments. Here the processor 102 of the informationhandling system 100 a executes a cache sharing application 250. FIG. 6illustrates the cache sharing application 250 stored within the localmemory 120 a, but the cache sharing application 250 may be stored insome other local or remotely accessible memory. Regardless, the cachesharing application 250 instructs the processor 102 to performoperations, such as allocating the cluster neighbor cache 240 a andtracking its dynamic size at various reporting times. Furthermore, theinformation handling system 100 a may also perform management functionsfor the cluster 220 and receive neighbor cache reports 252 from membernodes. Each neighbor cache report 252 is sent from a correspondingneighbor node (such as information handling systems 100 b-d). Eachrespective neighbor cache report 252 b-d identifies the cluster node(perhaps with a unique identifier) and specifies an available size (suchas bytes) of its corresponding cluster neighbor cache 240 b-d (perhapswith a timestamp). The cache sharing application 250 may poll the membernodes 100 b-d for their respective neighbor cache reports 252 b-d. Thecache sharing application 250 may recommend, or even command orinstruct, a particular member node to increase or decrease the size ofits cluster neighbor cache 240 b-d based on historical entries in anelectronic database 254 of the neighbor cache reports 240. The cachesharing application 250 may log and analyze past neighbor cache reports252 to identify historical usage (such as historical low and high memoryusage, size, allocation, and other factors). The cache sharingapplication 250 may track the cluster neighbor cache 240 b -d reportedby each member node and dynamically vary its size in relation to currentand/or historical need.

As FIG. 7 illustrates, exemplary embodiments may designate a clusterneighbor cache orchestration device 260. The cache sharing application250 may cause the cluster neighbor cache orchestration device 260 tomanage the member nodes 100 a -n in the cluster 220. That is, the cachesharing application 250 may be configured with administrative ormanagement functions that are reserved for any information handlingsystem 100 that orchestrates the cache memory sharing within the cluster220. Each member node 100 a-n allocates a portion of its local RAMmemory 120 a -n as the cluster neighbor cache 240 a-n. Other portions ofthe local RAM memory 120 a-n may be allocated for local storage of theI/O data 230 a and application memory space. If the local RAM memory 120a is unable to accommodate the I/O data 230, exemplary embodiments maysend or transfer the I/O data 230 a to a network address (such as IPaddress) associated with a different member node 100 b-n, perhaps asarranged or instructed by the cluster neighbor cache orchestrationdevice 260. The I/O data 230 a is thus remotely stored by a differentnode 100 b -n in the cluster 220. Exemplary embodiments may thus trackthe nodal destination for any disk blocks representing the I/O data 230.

FIG. 8 illustrates even more details. Here the electronic database 254may log or track any of the I/O data 230 transferred within the cluster220. For simplicity, FIG. 8 illustrates the electronic database 254 as atable 270 that electronically maps, relates, or associates the differentdisk blocks (representing the I/O data 230) to their corresponding nodallocation (such as unique nodal identifier 272 and cluster neighbor cache240 within the cluster 220). The I/O data 230 may be actual bit valuesof disk block(s) 274, a unique identifier 276, and/or a hash value 278.In short, whenever the I/O data 230 is shared within the cluster 220,exemplary embodiments may document or record an origination machine, adestination machine, and a time/date for subsequent or future retrieval.The electronic database 254 may thus be a central repository for the I/Odata 230 being shared or hosted by the virtual desktops 210 in thecluster 220. Exemplary embodiments may thus query the electronicdatabase 254 for a content representation of the I/O data 230 andidentify or retrieve the cluster neighbor cache 240 representing itscurrent storage location. Exemplary embodiments may also converselyquery for the current storage location (such as the cluster neighborcache 240) and identify or retrieve the corresponding I/O data 230stored thereby.

Exemplary embodiments thus describe a marketplace computing device whichuses off-host memory for disk IO caching, thus solving two fundamentalconcerns in modern IT environments—slow disk read time and the CPU poweroutpacing memory capacity (causing increased likelihood of memoryshortages on individual nodes). This can be particularly useful ingo-to-market approaches such as the ready-node approach for softwaredefined storage environments, where hardware nodes are brought to marketin a state that is “ready” for certain software defined storageenvironments (such as VMware VSAN, Dell EMC ScaleIO, and MicrosoftStorage Spaces Direct). Exemplary embodiments thus allow for marketdifferentiation and greater cluster performance.

Hashing may be used. The electronic database 254 identifies the I/O data230 shared within the cluster 220. While exemplary embodiments mayrepresent the I/O data 230 using any scheme, hash values may bepreferred. That is, the hash value 278 may be determined for each diskblock (representing the I/O data 230) using a hashing function 280.Hashing is well known and need not be explained. Suffice it to say thatthe electronic database 254 may store electronic database associationsbetween different hash values 278 and the nodal identifier 272associated with the cluster neighbor cache 240. When any I/O data 230 ishashed (using the hashing function 280), its corresponding hash value278 may be determined and an entry added to the electronic database 254.The electronic database 254 may thus be used to track which hash values278 are being shared by which ones of the cluster nodes. Exemplaryembodiments may thus generate a listing 282 of the I/O data 230 sharedwithin the cluster 220.

Exemplary embodiments may monitor for duplicates. The listing 282 of theI/O data 230 may also be sorted or arranged to reveal processingopportunities. For example, exemplary embodiments track identical I/Odata 230 (perhaps via their respective hash values 278) to eliminateduplicate sharing requests. Moreover, duplicate I/O data 230 may beeliminated or deleted from multiple machines, thus ensuring that eachcluster neighbor cache 240 is efficiently used.

Exemplary embodiments overcome latency issues. Conventional schemes onlylocally cache I/O read data to RAM memory. These conventional localcaching schemes mean that nodes with high application memory usage willonly be able to facilitate the caching of a small amount of disk IO toRAM, as the conventional schemes will only be able to host a small diskIO read cache. Some conventional schemes attempt to solve the problem ofmemory imbalance in a compute cluster by using RDMA to expose all of acluster's memory to a user application using an RDMA based approach.However, this RDMA exposure is only applicable to applications and doesnot reveal disk I/O cache. Moreover, other schemes may intelligentlyvary cache memory for disk I/O read caches based on node memory usage.That is, local cache is restricted to a single host and do not doanything to utilize an imbalance in memory usage in a cluster toincrease availability of memory read cache resources.

FIG. 9 illustrates memory sizing, according to exemplary embodiments.Here exemplary embodiments may size the cluster neighbor cache 240according to cluster needs. Suppose, for example, that the memory 120has a total capacity 290 of thirty-two gigabytes (32 GB). A portion ofthe memory 120 may be allocated as a software/firmware applicationmemory space 292 (perhaps storing the cache sharing application 250).Another portion of the memory 120 may be reserved as local cache 294 forlocal caching of the I/O data 230 (that is, local storage for diskblocks associated with local input/output read requests). Still anotherportion of the memory 120 may be allocated to the cluster neighbor cache240 for shared use of neighboring nodes in the cluster 220 (illustratedin FIGS. 3 and 5). A headroom 296 represents a remaining capacity of thememory 120. The headroom 296 may be defined as a difference between thetotal application memory space (such as 32 GB) and the peak applicationmemory usage (perhaps as historically revealed by the electronicdatabase 254). The peak application memory usage is generally asummation 298 of the application memory space 292, the local cache 294,and the cluster neighbor cache 240. In practice, then, the headroom 296may dynamically fluctuate in byte size in response to real time memoryusage. Indeed, the cache sharing application 250 may adjust the bytesize of the application memory space 292, the local cache 294, thecluster neighbor cache 240, and/or the headroom 296 according topresent, real time needs. Multiple nodes or hosts within the cluster 220may thus utilize the cluster neighbor cache 240 of a single machine.

FIG. 10 shows a method or algorithm for cache sharing between multiplenodes in the cluster 220, according to exemplary embodiments. Exemplaryembodiments may define or specify a minimum byte size of the headroom296 partitioned within the memory 120 (Block 300). When cache memorysharing commences (Block 302), exemplary embodiments monitor thereal-time byte size of the headroom 296 based on current usagerequirements (such as illustrated in FIG. 9). A current or availablebyte size or value of the headroom 296 is compared to the minimum bytesize of the headroom 296 (Block 304). If the available headroom 296 isless than the minimum byte size (Block 304), then the cluster neighborcache 240 may be reduced in size to increase the size of the headroom296 (Block 306). The size of the cluster neighbor cache 240, in otherwords, may be sacrificed in order to satisfy or attain the minimum bytesize of the headroom 296. If the available headroom 296 is equal to itsminimum byte size (Block 304), then the cluster neighbor cache 240 maybe correctly sized such that no resizing need occur (Block 308). If theavailable headroom 296 is greater than its minimum byte size (Block304), then the byte size of the cluster neighbor cache 240 may beincreased to increase or improve cache storage capacity (Block 310).Exemplary embodiments may repeat the headroom 296 calculation at anytime or according to a periodic re-evaluation.

While the computer-readable medium is shown to be a single medium, theterm “computer-readable medium” includes a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” shall also include any medium that is capableof storing, encoding, or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein.

In a particular non-limiting, exemplary embodiment, thecomputer-readable medium can include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories. Further, the computer-readable medium can be arandom access memory or other volatile re-writable memory. Additionally,the computer-readable medium can include a magneto-optical or opticalmedium, such as a disk or tapes or other storage device to storeinformation received via carrier wave signals such as a signalcommunicated over a transmission medium. Furthermore, a computerreadable medium can store information received from distributed networkresources such as from a cloud-based environment. A digital fileattachment to an e-mail or other self-contained information archive orset of archives may be considered a distribution medium that isequivalent to a tangible storage medium. Accordingly, the disclosure isconsidered to include any one or more of a computer-readable medium or adistribution medium and other equivalents and successor media, in whichdata or instructions may be stored.

When referred to as a “device,” a “module,” or the like, the embodimentsdescribed herein can be configured as hardware. For example, a portionof an information handling system device may be hardware such as, forexample, an integrated circuit (such as an Application SpecificIntegrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), astructured ASIC, or a device embedded on a larger chip), a card (such asa Peripheral Component Interface (PCI) card, a PCI-express card, aPersonal Computer Memory Card International Association (PCMCIA) card,or other such expansion card), or a system (such as a motherboard, asystem-on-a-chip (SoC), or a stand-alone device).

Devices, modules, resources, or programs that are in communication withone another need not be in continuous communication with each other,unless expressly specified otherwise. In addition, devices, modules,resources, or programs that are in communication with one another cancommunicate directly or indirectly through one or more intermediaries.

Although only a few exemplary embodiments have been described in detailherein, those skilled in the art will readily appreciate that manymodifications are possible in the exemplary embodiments withoutmaterially departing from the novel teachings and advantages of theembodiments of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of theembodiments of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents, but also equivalent structures.

What is claimed is:
 1. A method, comprising: receiving, by a processoroperating in a computing node, input/output data associated with a harddisk drive, the computing node associated with a virtual computingcluster; determining, by the processor, a local random access memoryoperating in the computing node is unavailable for a storage of theinput/output data; and transferring, by the processor, the input/outputdata to a cluster neighbor cache operating in another computing nodeassociated with the virtual computing cluster, the other computing nodeestablishing the cluster neighbor cache as a shared resource for thestorage of the input/output data associated with the cluster; whereinthe cluster neighbor cache remotely stores the input/output data inresponse to the local random access memory being unavailable.
 2. Themethod of claim 1, further comprising retrieving the input/output datafrom the cluster neighbor cache operating in the other computing nodeassociated with the cluster.
 3. The method of claim 1, furthercomprising querying the cluster neighbor cache to retrieve theinput/output data from the other computing node associated with thecluster.
 4. The method of claim 1, further comprising logging thetransferring of the input/output data to the cluster neighbor cacheoperating in the other computing node.
 5. The method of claim 1, furthercomprising storing, in a memory accessible to the processor, anelectronic database having electronic database associations between theinput/output data and an identifier associated with the cluster neighborcache.
 6. The method of claim 1, further comprising storing, in a memoryaccessible to the processor, an electronic database having electronicdatabase associations between the input/output data and an identifierassociated with the other computing node.
 7. The method of claim 1,further comprising storing, in a memory accessible to the processor, anelectronic database having electronic database associations between theinput/output data and an identifier associated with the cluster.
 8. Themethod of claim 1, further comprising storing, in a memory accessible tothe processor, an electronic database having electronic databaseassociations between the input/output data and at least one identifierassociated with the cluster neighbor cache, the other computing node,and the cluster.
 9. The method of claim 1, further comprisingidentifying multiple occurrences of the input/output data stored withinthe virtual computing cluster.
 10. The method of claim 1, furthercomprising sizing the cluster neighbor cache.
 11. A machine comprising:a processor; and a local random access memory accessible to theprocessor, the local random access memory storing instructions that whenexecuted cause the processor to perform operations including: receivinginput/output data associated with a hard disk drive; determining thelocal random access memory is unavailable for a cache storage of theinput/output data; and transferring the input/output data to a clusterneighbor cache operating in another computing node associated with avirtual computing cluster, the other computing node establishing thecluster neighbor cache as a shared resource for the cache storage of theinput/output data associated with the cluster; wherein the clusterneighbor cache remotely stores the input/output data in response to thelocal random access memory being unavailable.
 12. The machine of claim11, wherein the operations further include retrieving the input/outputdata from the cluster neighbor cache operating in the other computingnode associated with the cluster.
 13. The machine of claim 11, whereinthe operations further include querying the cluster neighbor cache toretrieve the input/output data from the other computing node associatedwith the cluster.
 14. The machine of claim 11, wherein the operationsfurther include logging the transferring of the input/output data to thecluster neighbor cache operating in the other computing node.
 15. Themachine of claim 11, wherein the operations further include storing anelectronic database having electronic database associations between theinput/output data and an identifier associated with the cluster neighborcache.
 16. The machine of claim 11, wherein the operations furtherinclude storing an electronic database having electronic databaseassociations between the input/output data and an identifier associatedwith the other computing node.
 17. The machine of claim 11, wherein theoperations further include storing an electronic database havingelectronic database associations between the input/output data and atleast one identifier associated with the cluster neighbor cache, theother computing node, and the cluster.
 18. A method comprising:receiving input/output data associated with a hard disk drive;determining a local random access memory is unavailable for a cachestorage of the input/output data; and transferring the input/output datavia a communications network to a cluster neighbor cache operating in acomputing node associated with a cluster in a virtual computingenvironment, the computing node establishing the cluster neighbor cacheas a shared resource for the cache storage of the input/output dataassociated with the cluster; wherein the cluster neighbor cache remotelystores the input/output data in response to the local random accessmemory being unavailable.
 19. The method of claim 18, wherein theoperations further include retrieving the input/output data from thecluster neighbor cache operating in the computing node associated withthe cluster.
 20. The method of claim 18, wherein the operations furtherinclude querying the cluster neighbor cache to retrieve the input/outputdata from the computing node associated with the cluster.